Hello Eric,

Thank you, all of the issues named previous have been addressed; I have merged the PR.

As promised, I do have a couple functional comments for your consideration. None of these needs to be addressed before we deploy (if ever), but I did want to share:

• As a DJ moves spins up or down in the playlist editor, can zk really know the specific times of those spins anymore? As it stands now, the timestamp does not move with the spin, which seems correct... one would not want to move the timestamp, as the times in the playlist would then be out of temporal order. However, one other solution would be to clear the timestamps of the two tracks involved the move, since moving the spins suggests we can't reasonably guess times anymore. I am not fussed about this and it seems fine either way; it is just that I have some doubts about what the correct/expected behaviour should be.

• Right now, Import Playlist is timestamping the playlist if it is imported within the window of the show. There is at least one DJ who does this sometimes. The result is that the moment of import is getting timestamped onto every spin in the playlist. This is a somewhat rare edge case, but it does happen. One suggestion is the following: Keep the time test logic in insertTrack the same, but add a new parameter to insertTrack (both on the implementation and the prototype class IPlaylist) to force automatic timestamps off. This parameter would override timestamping, so that even if insertTrack's time window test would otherwise succeed, no timestamp would be applied. There is only one vector where timestamps are applicable (ui/Playlists.php and any possible future JSON API playlist code in support of Angular/client-side playlist editing). Those invocations could set the parameter to apply the automatic timestamp logic.

Thank you again for this contribution, and for your suggestions to unify the branches and to enhance the installation instructions. Your contributions are making zookeeper even better!